Obi is an object oriented preprocessor for Aztec C. It allows functions (also called methods or messages) to be applied to data records call objects. Obi is my attempt at creating a fast and useful object oriented language for the Macintosh.
The current release (V1.0) has several limitations which may reduce its usefulness. These limitations are 1) that all object and C code must be in one file at translation time, 2) there are very few predefined class that currently exist 3) method names must be very short because of the eight character limit for ID's in Aztec C.
On the plus side, 1) it allows for modular programming 2) it is very fast for an object oriented language since there in no interpretation done at run time 3) it is very easy to reuse code.
I hope this is a useful program for those of you that have been waiting patiently for an object oriented developement system. Because of the limitations in this release I am releasing it into the public domain. As future versions become more robust they may be released as FreeWare.
Terminology
I guess before I dive into this I should say that I am not an expert on object oriented programming nor do I know Smalltalk. I do believe I am using the terminology the same way it is applied to Smalltalk but if I'm not, well I plead ignorance.
A Class is collection of Objects and Methods or Messages which may be applied to them. An Object is actually a record or structure and a Method is really a function.
Each Class is made up of two kinds of Objects. These are Class objects
and Instance objects. A Class object always exists. It holds most of the global information the Class needs. In general it's job is to do things like creating new Instance objects. Instance objects are the individual objects created at runtime. For example if there were a Class WINDOW that knew about Macintosh window, each individual window on the screen would actually correspond to its own Instance object.
Each kind of object has its own kind of variable. The Class object has Class Variables which are thought of as variables global to all Instance objects in the Class. The Instance object has Instance Variables which are unique to each Instance Object.
Each kind of object also has its own kind of Method or Message. The Class object has the Class Methods which are functions which can only be applied to Class Objects. The Instance Object has Instance Methods which may only be applied to Instance Objects.
Classes also have a superclass which is the class the currently defined class inherits from. All Instance and Class methods and variables that are availible to the Superclass are also availible to the Class. This means that a Class TEWIN whose superclass in WINDOW contains all the varibles of WINDOW and knows about all of its Methods. This is how code is reused in the object oriented environment.
There are also three other special keywords that are used in Obi. These are self, super, and object. The word self is used when refering to the current Class while in a Method definition. The word super also refers to the current Class while in a Method definition, however it also causes the superclasses methods to be executed rather than the objects Classes methods. The word object is used when defining object variables.
There is also one special definition. It is object Generic. It is how one refers to any (unknown) object. Messages may be sent to an object Generic and since an individual object knows what it is, the correct method will be executed even though there is no actual Generic object.
Message are sent to objects using the following syntax : "messageName => obj(arguments)". This means, apply the Method "messageName" to the the object "obj".
Stucture of Obi Programs
A program written in Obi contains a series of Class definitions followed by C code. A Class definition is as follows
/*< class CLASSNAME >*/
/*< super SUPERNAME >*/
/*< defines >*/
Normal C defines required for the Class.
/*< variables class
Normal C varible definitions for the Class Object.
>*/
/*< variables instance
Normal C variable definitions for the Instance Objects.
>*/
/*< methods class >*/
Class method definitions.
/*< methods instance >*/
Instance method definitions.
All the Class definitions are place at the top of an Obi program. A class which is used as a super to another Class must be define before it is used. The C code is seperated from the Class definitions by several '%'. Any definitions following '%' are interpreted as C functions.
A Sample Class Definition
The following object is the Class Object. All objects must inherit from this object either directly or indirectly through its superclass. Object contains no Class or Instance variables. Its only function is to create new objects.
/*
* This is the OBJECT Class. It is the root of
* all objects.
*/
/*< class OBJECT >*/
/*< super NULL >*/
/*< defines >*/
/*< variables class >*/
/*< variables instance >*/
/*< methods class */
/*
* Dynamically create a new object.
*/
object Generic *
new()
{
object Generic *ptr;
/* get memory for the requested object */
ptr = (object Generic *) malloc(self.size);
/* make the memory into request object */
objectify => self(ptr);
}
/*
* Convert memory into a requested Instance object
*/
objectify(ptr)
object Generic *ptr;
{
/*
* Take information from the Class object
* and fill it in the current Instance object.
*/
ptr->classType = self.classType;
ptr->superType = self.superType;
ptr->size = self.size;
/*
* Add pointer to table of Instance Methods.
*/
ptr->funcTbl = InstTbl;
}
/*< methods instance >*/
/* None.*/
Now lets define a class which has OBJECT as its superclass. This new object will be called TEST and its only funtion will be to view and set an integer .
/*< class TEST >*/
/*< super OBJECT >*/
/*< defines >*/
/*< variables class >*/
/*< variables instance
int value;
>*/
/*< methods class */
/* None. */
/*< methods instance >*/
/*
* Set the Instance variable value.
*/
set(value)
int value;
{
self.value = value;
}
/*
* Returns the Instance variable value.
*/
view()
{
return self.value;
}
Some thing to notice is that methods for a class are referenced via a lookup table. This means that a bizarre type is actually returned from a method so any value must be cast into the correct type. Sorry, its the best I could do in a short time.
Now lets put use the two class in a program. Here is how objects are created and called from a C function. In this case the C function is main().
main()
{
/*
* Remember, test1 is a pointer to an object and
* therefore has no actual storage allocated for it
* while test2 has storage for an object already
* allocated and ready for use.
*/
object TEST *test1, test2;
/*
* The message "new" is sent to the Class object
* "TEST" which dynamically creates a new instance
* object for Class TEST. Notice the returned value is
* cast to the correct type.
*/
test1 = (object TEST *) new => TEST();
/*
* The message "objectify" sent to the Class object
The Important things to remember here are that pointers to objects must be dereferenced when applying messages to it and that return values must be cast into the expected return type.
How It Really Works
In this section I will give an overview of what the C code looks like after Obi has munged it. It's really fairly straight forward but you probably don't need to know this to use Obi. Though it will help alot when you are debugging code.
The reason Obi is possible at all is because C allows you to casually cast things from one type to another. This means that the C structs for all object have the same first four definitions. These are the classType, superType, size and funcTbl. These are all the definitions required to create and send messages to an object. The definition of object Generic only contains this information. The actual C structure is -
typedef struct Generic_body (
int classType;
int superType;
int size;
FUNC *funcTbl;
} Generic_body;
The structure is actually called Generic_body because all definitions of the form object OBJECTNAME are translated by Obi into OBJECTNAME_body. All Instance objects structures are called OBJECTNAME_body. All Class objects are of the form OBJECTNAME_head.
These may not be the most descriptive names but I'm too lazy to change them.
The definitions self and super are translated into (*receiver). Super is special though because it affects how a message is translated.
Messages of the form "messageName => obj(C args)" are translated into
(obj).funcTbl[(obj).classType][message_Index](&(obj), C args);
Message of the form "message => self(C args)" are translated into
(*receiver).funcTbl[(*receiver).classType][message_Index](&(*receiver), C args);
Finally message of the form "message => super(C args)" are translated into
(*receiver).funcTbl[CLASSES_SUPER][message_Index](&(*receiver), C args);
Class Method definitions of the form
methodName()
{
}
Become
MmethodName_CLASS(receiver)
object CLASS *receiver;
{
}
Instance Method definitions of the form
methodName()
{
}
Become
ImethodName_CLASS(receiver)
object CLASS *receiver;
{
}
From the above discussions and examples it is probably obvious that I lied a bit in the introduction when I said there is no interpretation done at run time. However the interpretation consists of indexing into an array of function pointers to decide what the proper method is to execute for the current object. The overhead required to do this is fairly small when comparing it to how this is handled in other object programming systems. I hope you don't feel misled about this.
Command Syntax
I originally wrote Obi on a VAX under bsd4.2. Because of this it is a fairly generic Unix application (though I'm not currently interested in porting it to machines other than the Mac under Aztec C). The syntax of the Obi command is: "obi [-v|-t] [-d] filename.obi". The flag "-v" stands for verbose while "-t" stands for terse. They are mutually exclusive flags. The flag "-d" is debug mode for the translator. It causes Methods and messages to generate slightly different code to aid in tracking down "doesNotRespond" errors.
Known Bugs
In my rush to get V1.0 out I have found several bugs which aren't fatal but you should be aware of. These problems will be fixed in the next release.
• Definitions of the form object CLASS aren't properly translated in both the variables instance and variable class sections. The work around for this is to use definitions of the form struct CLASS_body.
• Double quoted strings must not contain an escaped double quote. This cause Obi to become confused. Also single quotes must not contain an escaped single quote.
• Error messages leave alot to be desired.
• Method name must be fairly short because of Aztec C's eight character ID limit.
In general I have been testing Obi with "correct" programs so I can't actually say with 100% confidence that it will act sanely for "incorrect" programs. I have been using it to translate an ~800 line program and I believe I've fixed all the fatal errors and most of the nasty none fatal problems. But who knows?
Conclusion
Hopefully with this and a demo program is sufficient to get you started with Obi. I plan to improve Obi. There are some obvious improvements to be made to Obi. However, I would definitely like to hear suggestions for improvement to Obi. I am also interested in acquiring interesting CLASS definitions for the Macintosh. If you write an interesting CLASS please send it to me. If you don't want it to become part of the Obi distribution be sure and tell me that too.
If you are still stuck on what object programming is all about try reading about Smalltalk in May 85 Byte or better yet the article on Software IC's in June 85 Byte.
One Last Thing
Nothing I've done in Obi is new or original. I've used techniques that other object oriented preprocessors use. However, I have spent a bit of time writing this program and would like to get something from distributing it so please send me your opinions (good or bad), any CLASS definitions you think are useful and suggested improvements.
